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Indicating Support for Interactive Connectivity Establishment (ICE) 
in the Session Initiation Protocol (SIP) 

Abstract 
This specification defines a media feature tag and an option tag for 
use with the Session Initiation Protocol (SIP). The media feature 
tag allows a User Agent (UA) to communicate to its registrar that it 
supports ICE. The option tag allows a UA to require support for ICE 
in order for a call to proceed. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5768. 


Copyright Notice 


Copyright (c) 2010 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


RFC 3264 [RFC3264] defines a two-phase exchange of Session 
Description Protocol (SDP) [RFC4566] messages for the purposes of 


establishment of multimedia sessions. This offer/answer mechanism is 
used by protocols such as the Session Initiation Protocol (SIP) 
[RFC3261]. 


Protocols using offer/answer are difficult to operate through Network 
Address Translators (NAT). Because their purpose is to establish a 
flow of media packets, they tend to carry IP addresses within their 
messages, which is known to be problematic through NAT [RFC3235]. To 
remedy this, an extension to SDP, called Interactive Connectivity 
Establishment (ICE) has been defined [RFC5245]. ICE defines 
procedures by which agents gather a multiplicity of addresses, 
include all of them in an SDP offer or answer, and then use peer-to- 
peer Session Traversal Utilities for NAT (STUN) [RFC5389] 
connectivity checks to determine a valid address. 


This specification defines a media feature tag, "Sip.ice", and a SIP 
option tag, "ice", that can be used by SIP User Agents that make use 
of ICE. Section 3 motivates the need for the media feature tag and 
option tag, and Section 4 and Section 5 formally define them. 


2. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
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3. Motivation 


There are two primary motivations for defining an option tag and a 
media feature tag. They are support for gateways, and requiring ICE 
for a call. 


3.1. Gateways 


Unfortunately, ICE requires both endpoints to support it in order for 
it to be used. Within a domain, there will typically be User Agents 
that do and do not support ICE. In order to facilitate deployment of 
ICE, it is anticipated that domains will make use of gateways that 
act as ICE agents on one side, and non-ICE agents on the other side. 
This would allow a call from domain A into domain B to make use of 
ICE, even if the device in domain B does not itself yet support ICE. 
However, when domain B receives a call, it will need to know whether 
the call needs to pass through such a gateway, or whether it can go 
to the terminating UA directly. 


In order to make such a determination, this specification defines a 
media feature tag, "Sip.ice", which can be included in the Contact 
header field of a REGISTER request [RFC3840]. This allows the 
registrar to track whether or not a UA supports ICE. This 
information can be accessed by a proxy in order to determine whether 
or not a call needs to route through a gateway. 


3.2. Mandating Support for ICE 


Although ICE provides a built in fall back to non-ICE operation when 
the answerer doesn’t support it, there are cases where the offerer 
would rather abort the call rather than proceed without ICE. 
Typically, this is because they would like to choose a different m/c- 
line address for a non-ICE peer than they would for an ICE capable 
peer. 


To do this, the "ice" SIP option tag can be included in the Require 
header field of an INVITE request. 


4. Media Feature Tag Definition 


The "Sip.ice" media feature tag indicates support for ICE. An agent 
supports ICE if it is either a lite or full implementation, and 
consequently, is capable of including candidate attributes in an SDP 
offer or answer for at least one transport protocol. An agent that 
supports ICE SHOULD include this media feature tag in the Contact 
header field of its REGISTER requests and OPTION responses. 
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An agent MAY include the media feature tag in the Contact header 
field of an INVITE or INVITE response; however, doing so is redundant 
with ICE attributes in the SDP that indicate the same thing. In 
cases where an INVITE omits an offer, the lack or presence of the 
media feature tag in the Contact header field cannot be used by the 
callee (which will be the offerer) to determine whether the caller 
supports ICE. In cases of third-party call control [RFC3725], the 
caller may be a controller that does (or doesn’t) support ICE, while 
the answerer may be an agent that does (or doesn’t) support ICE. 


5. Option Tag Definition 


This "ice" OPTION tag SHOULD NOT be used in conjunction with the 
Supported header field (this SHOULD NOT include responses to OPTION 
requests). The media feature tag is used as the one and only 
mechanism for indicating support for ICE. The option tag is meant to 
be used only with the Require header field. When placed in the 
Require header field of an INVITE request, it indicates that the User 
Agent Server (UAS) must support ICE in order to process the call. An 
agent supports ICE if it is either a full or lite implementation, and 
consequently, is capable of including candidate attributes in an SDP 
offer or answer for at least one transport protocol. 


6. Security Considerations 


A malicious intermediary might attempt to modify a SIP message by 
inserting a Require header field containing the "ice" option tag. If 
ICE were not supported on the UAS, this would cause the call to fail 
when it would otherwise succeed. Of course, this attack is not 
specific to ICE, and can be done using any option tag. This attack 
is prevented by usage of the SIPS mechanism as defined in RFC 3261. 


Similarly, an intermediary might attempt to remove the media feature 
tag from a REGISTER request or OPTIONS request, which might cause a 
call to skip ICE processing when it otherwise might make use of it. 
This attack is also prevented using the SIPS mechanism. 

7. IANA Considerations 


This specification defines a new media feature tag and SIP option 
tag. 


7.1. Option Tag 


This section defines a new SIP option tag per the guidelines in 
Section 27.1 of RFC 3261. 
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Name: ice 


Description: This option tag is used to identify the Interactive 
Connectivity Establishment (ICE) extension. When present in a 
Require header field, it indicates that ICE is required by an 
agent. 


7.2. Media Feature Tag 


This section registers a new media feature tag in the SIP tree, 
defined in Section 12.1 of RFC 3840 [RFC3840]. 


Media feature tag name: sip.ice 

ASN.1 Identifier: 1.3.6.1.8.4.22 

Summary of the media feature indicated by this tag: This feature tag 
indicates that the device supports Interactive Connectivity 
Establishment (ICE). 

Values appropriate for use with this feature tag: Boolean. 

The feature tag is intended primarily for use in the following 
applications, protocols, services, or negotiation mechanisms: 
This feature tag is most useful in a communications application, 
for describing the capabilities of a device, such as a phone or 


PDA. 


Examples of typical use: Routing a call to a phone that can support 
ICE. 


Related standards or documents: RFC 5768 


Security Considerations: Security considerations for this media 
feature tag are discussed in Section 6 of this document. 
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